Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

chore(deps): update dependency apple/swift-syntax to v600 #32

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

renovate[bot]
Copy link

@renovate renovate bot commented Sep 13, 2024

This PR contains the following updates:

Package Update Change
apple/swift-syntax major 0.50100.0 -> 600.0.1

Release Notes

apple/swift-syntax (apple/swift-syntax)

v600.0.1

Compare Source

Compared to 600.0.0 this release fixes a compilation issue when building swift-syntax in C++ interop mode (https://github.com/swiftlang/swift-syntax/pull/2861).

It also contains the following changes from 600.0.0.

New APIs

Deprecations

  • Child Choice Node Casts

  • IncrementalParseTransition:

  • MacroExpansion{Error|Warning|FixIt}Message moved to the SwiftSyntaxMacros module

    • Description: Move the MacroExpansion{Error|Warning|FixIt}Message types from the SwiftSyntaxMacroExpansion module to SwiftSyntaxMacros. Deprecated typealiases in SwiftSyntaxMacroExpansion forward to SwiftSyntaxMacros.
    • Pull request: https://github.com/swiftlang/swift-syntax/pull/2338
    • Notes: The expansion diagnostic messages were defined in SwiftSyntaxMacroExpansion, which is intended as an implementation detail of the plugin server and should not need to be imported by macros.
  • EditorPlaceholderDeclSyntax and EditorPlaceholderExprSyntax:

    • Description: EditorPlaceholderDeclSyntax and EditorPlaceholderExprSyntax are now deprecated and placeholders are instead parsed as identifiers within a MissingDeclSyntax or DeclReferenceExprSyntax.
    • Pull request: https://github.com/swiftlang/swift-syntax/pull/2237
  • AttributedTypeSyntax.specifier has renamed to specifiers and changed to be a collection

  • CanImportExprSyntax and CanImportVersionInfoSyntax

    • Description: Instead of parsing canImport inside #if directives as a special expression node, parse it as a functionc call expression. This is in-line with how the swift(>=6.0) and compiler(>=6.0) directives are parsed.
    • Pull request: https://github.com/swiftlang/swift-syntax/pull/2025

API-Incompatible Changes

  • MacroDefinition used for expanding macros:

    • Description: The MacroDefinition/expansion enum case used to have two values ((MacroExpansionExprSyntax, replacements: [Replacement])), has now gained another value in order to support generic argument replacements in macro expansions: (MacroExpansionExprSyntax, replacements: [Replacement], genericReplacements: [GenericArgumentReplacement])
    • Pull request: https://github.com/swiftlang/swift-syntax/pull/2450
    • Migration steps: Code which exhaustively checked over the enum should be changed to case .expansion(let node, let replacements, let genericReplacements):. Creating the .extension gained a compatibility shim, retaining the previous syntax source compatible (return .expansion(node, replacements: [])).
  • Effect specifiers:

    • Description: The unexpectedAfterThrowsSpecifier node of the various effect specifiers has been removed.
    • Pull request: https://github.com/swiftlang/swift-syntax/pull/2219
    • Migration steps: Check unexpectedBetweenThrowsSpecifierAndThrownError and unexpectedAfterThrownError instead.
  • SyntaxKind removed conformance to CaseIterable

    • Description: SyntaxKind no longer conforms to CaseIterable since there is no good use case to iterate over all syntax kinds.
    • Pull request: https://github.com/swiftlang/swift-syntax/pull/2292
    • Migration steps: Exhaustively check all the syntax nodes that your program supports. There should be no use case to iterate over all cases in SyntaxKind.
  • IntegerLiteralExprSyntax.Radix removed conformance to CaseIterable

    • Description: IntegerLiteralExprSyntax.Radix no longer conforms to CaseIterable since there is no good use case to iterate over all radix kinds.
    • Pull request: https://github.com/swiftlang/swift-syntax/pull/2292
    • Migration steps: There should be no use case to iterate over all cases in IntegerLiteralExprSyntax.Radix.
  • Parser.parseIncrementally(source:parseTransition:) and Parser.parseIncrementally(source:maximumNestingLevel:parseTransition:):

  • SyntaxClassification gained a new case: argumentLabel

    • The new classification case covers the first names of parameters in function-like declarations and the label of arguments in function-like calls.
    • Pull request: https://github.com/swiftlang/swift-syntax/pull/2375
    • Migration steps: In exhaustive switches over SyntaxClassification, cover the new case.
  • SyntaxEnum and SyntaxKind gained new cases: throwsClause

  • MacroExpansionContext now requires a property lexicalContext:

    • Description: The new property provides the lexical context in which the macro is expanded, and has several paired API changes. Types that conform to MacroExpansionContext will need to implement this property. Additionally, the HostToPluginMessage cases expandFreestandingMacro and expandAttachedMacro now include an optional lexicalContext. Finally, the SyntaxProtocol.expand(macros:in:indentationWidth:) syntactic expansion operation has been deprecated in favor of a new version expand(macros:contextGenerator:indentationWidth:) that takes a function produces a new macro expansion context for each expansion.
    • Pull request: https://github.com/swiftlang/swift-syntax/pull/1554
    • Migration steps: Add the new property lexicalContext to any MacroExpansionContext-conforming types. If implementing the host-to-plugin message protocol, add support for lexicalContext. For macro expansion operations going through SyntaxProtocol.expand, provide a context generator that creates a fresh context including the lexical context.
  • TriviaPiece.isBackslash in SwiftParserDiagnostics removed

  • All symbols in SwiftCompilerPluginMessageHandling are now SPI

v600.0.0

Compare Source

New APIs

Deprecations

  • Child Choice Node Casts

  • IncrementalParseTransition:

  • MacroExpansion{Error|Warning|FixIt}Message moved to the SwiftSyntaxMacros module

    • Description: Move the MacroExpansion{Error|Warning|FixIt}Message types from the SwiftSyntaxMacroExpansion module to SwiftSyntaxMacros. Deprecated typealiases in SwiftSyntaxMacroExpansion forward to SwiftSyntaxMacros.
    • Pull request: https://github.com/swiftlang/swift-syntax/pull/2338
    • Notes: The expansion diagnostic messages were defined in SwiftSyntaxMacroExpansion, which is intended as an implementation detail of the plugin server and should not need to be imported by macros.
  • EditorPlaceholderDeclSyntax and EditorPlaceholderExprSyntax:

    • Description: EditorPlaceholderDeclSyntax and EditorPlaceholderExprSyntax are now deprecated and placeholders are instead parsed as identifiers within a MissingDeclSyntax or DeclReferenceExprSyntax.
    • Pull request: https://github.com/swiftlang/swift-syntax/pull/2237
  • AttributedTypeSyntax.specifier has renamed to specifiers and changed to be a collection

  • CanImportExprSyntax and CanImportVersionInfoSyntax

    • Description: Instead of parsing canImport inside #if directives as a special expression node, parse it as a functionc call expression. This is in-line with how the swift(>=6.0) and compiler(>=6.0) directives are parsed.
    • Pull request: https://github.com/swiftlang/swift-syntax/pull/2025

API-Incompatible Changes

  • MacroDefinition used for expanding macros:

    • Description: The MacroDefinition/expansion enum case used to have two values ((MacroExpansionExprSyntax, replacements: [Replacement])), has now gained another value in order to support generic argument replacements in macro expansions: (MacroExpansionExprSyntax, replacements: [Replacement], genericReplacements: [GenericArgumentReplacement])
    • Pull request: https://github.com/swiftlang/swift-syntax/pull/2450
    • Migration steps: Code which exhaustively checked over the enum should be changed to case .expansion(let node, let replacements, let genericReplacements):. Creating the .extension gained a compatibility shim, retaining the previous syntax source compatible (return .expansion(node, replacements: [])).
  • Effect specifiers:

    • Description: The unexpectedAfterThrowsSpecifier node of the various effect specifiers has been removed.
    • Pull request: https://github.com/swiftlang/swift-syntax/pull/2219
    • Migration steps: Check unexpectedBetweenThrowsSpecifierAndThrownError and unexpectedAfterThrownError instead.
  • SyntaxKind removed conformance to CaseIterable

    • Description: SyntaxKind no longer conforms to CaseIterable since there is no good use case to iterate over all syntax kinds.
    • Pull request: https://github.com/swiftlang/swift-syntax/pull/2292
    • Migration steps: Exhaustively check all the syntax nodes that your program supports. There should be no use case to iterate over all cases in SyntaxKind.
  • IntegerLiteralExprSyntax.Radix removed conformance to CaseIterable

    • Description: IntegerLiteralExprSyntax.Radix no longer conforms to CaseIterable since there is no good use case to iterate over all radix kinds.
    • Pull request: https://github.com/swiftlang/swift-syntax/pull/2292
    • Migration steps: There should be no use case to iterate over all cases in IntegerLiteralExprSyntax.Radix.
  • Parser.parseIncrementally(source:parseTransition:) and Parser.parseIncrementally(source:maximumNestingLevel:parseTransition:):

  • SyntaxClassification gained a new case: argumentLabel

    • The new classification case covers the first names of parameters in function-like declarations and the label of arguments in function-like calls.
    • Pull request: https://github.com/swiftlang/swift-syntax/pull/2375
    • Migration steps: In exhaustive switches over SyntaxClassification, cover the new case.
  • SyntaxEnum and SyntaxKind gained new cases: throwsClause

  • MacroExpansionContext now requires a property lexicalContext:

    • Description: The new property provides the lexical context in which the macro is expanded, and has several paired API changes. Types that conform to MacroExpansionContext will need to implement this property. Additionally, the HostToPluginMessage cases expandFreestandingMacro and expandAttachedMacro now include an optional lexicalContext. Finally, the SyntaxProtocol.expand(macros:in:indentationWidth:) syntactic expansion operation has been deprecated in favor of a new version expand(macros:contextGenerator:indentationWidth:) that takes a function produces a new macro expansion context for each expansion.
    • Pull request: https://github.com/swiftlang/swift-syntax/pull/1554
    • Migration steps: Add the new property lexicalContext to any MacroExpansionContext-conforming types. If implementing the host-to-plugin message protocol, add support for lexicalContext. For macro expansion operations going through SyntaxProtocol.expand, provide a context generator that creates a fresh context including the lexical context.
  • TriviaPiece.isBackslash in SwiftParserDiagnostics removed

  • All symbols in SwiftCompilerPluginMessageHandling are now SPI

v510.0.3

Compare Source

Compared to 510.0.2 improves swift-syntax’s ability to build using Bazel.

It also contains the following changes from 510.0.0.

New APIs

Deprecations

API-Incompatible Changes

  • NoteMessage.fixItID renamed to noteID

  • DiagnosticSpec.highlight replaced by highlights

    • Description: The use of a single string highlight prevented users from asserting that a macro highlighted exactly the expected set of syntax nodes. Use of DiagnosticSpec.init(...highlight:...) is deprecated and forwards to DiagnosticSpec.init(...highlights:...). Migrating from highlight to highlights is straightforward; any uses of DiagnosticSpec.init which do not specify a highlight do not need to change, otherwise:
      • If the diagnostic highlights a single node, the highlight string should be replaced with a single element array containing the same string without any trailing trivia, e.g., highlight: "let " -> highlights: ["let"].
      • If the diagnostic highlights multiple nodes, the highlight string should be replaced with an array containing an element for each highlighted node, e.g., highlight: "struct {}" -> highlights: ["struct", "{}"].
    • Pull Request: https://github.com/apple/swift-syntax/pull/2213

v510.0.2

Compare Source

Compared to 510.0.1 this release fixes compilation warnings about retroactive conformances when building swift-syntax with a Swift 6 compiler.

It also contains the following changes from 510.0.0.

New APIs

Deprecations

API-Incompatible Changes

  • NoteMessage.fixItID renamed to noteID

  • DiagnosticSpec.highlight replaced by highlights

    • Description: The use of a single string highlight prevented users from asserting that a macro highlighted exactly the expected set of syntax nodes. Use of DiagnosticSpec.init(...highlight:...) is deprecated and forwards to DiagnosticSpec.init(...highlights:...). Migrating from highlight to highlights is straightforward; any uses of DiagnosticSpec.init which do not specify a highlight do not need to change, otherwise:
      • If the diagnostic highlights a single node, the highlight string should be replaced with a single element array containing the same string without any trailing trivia, e.g., highlight: "let " -> highlights: ["let"].
      • If the diagnostic highlights multiple nodes, the highlight string should be replaced with an array containing an element for each highlighted node, e.g., highlight: "struct {}" -> highlights: ["struct", "{}"].
    • Pull Request: https://github.com/apple/swift-syntax/pull/2213

v510.0.1

Compare Source

Compared to 510.0.0 this fixes a possible misaligned memory access.

It also contains the following changes from 510.0.0.

New APIs

Deprecations

API-Incompatible Changes

  • NoteMessage.fixItID renamed to noteID

  • DiagnosticSpec.highlight replaced by highlights

    • Description: The use of a single string highlight prevented users from asserting that a macro highlighted exactly the expected set of syntax nodes. Use of DiagnosticSpec.init(...highlight:...) is deprecated and forwards to DiagnosticSpec.init(...highlights:...). Migrating from highlight to highlights is straightforward; any uses of DiagnosticSpec.init which do not specify a highlight do not need to change, otherwise:
      • If the diagnostic highlights a single node, the highlight string should be replaced with a single element array containing the same string without any trailing trivia, e.g., highlight: "let " -> highlights: ["let"].
      • If the diagnostic highlights multiple nodes, the highlight string should be replaced with an array containing an element for each highlighted node, e.g., highlight: "struct {}" -> highlights: ["struct", "{}"].
    • Pull Request: https://github.com/apple/swift-syntax/pull/2213

v510.0.0

Compare Source

New APIs

  • SyntaxStringInterpolation.appendInterpolation(_: (some SyntaxProtocol)?)

  • SyntaxCollection.index(at:)

  • Convenience initializer ClosureCaptureSyntax.init()

    • Description: Provides a convenience initializer for ClosureCaptureSyntax that takes a concrete name argument and automatically adds equal = TokenSyntax.equalToken() to it.
    • Issue: https://github.com/apple/swift-syntax/issues/1984
    • Pull Request: [https://github.com/appl

Configuration

📅 Schedule: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined).

🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.

Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about this update again.


  • If you want to rebase/retry this PR, check this box

This PR was generated by Mend Renovate. View the repository job log.

@renovate renovate bot force-pushed the renovate/apple-swift-syntax-600.x branch from 25b90df to 3a56dfd Compare September 25, 2024 18:31
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

0 participants